The future of LISP and how to get there

1. Include the politics, starting with the political
dangers.

big floats as an illustration

combine with prolog, but what about control specification

is Scheme advanced enough?  Ask Carolyn.

	I think Common Lisp should be standardized, but I also favor an
effort to make a more advanced Lisp language.

	Before discussing my ideas about what should be in the language,
I want to discuss the politics.  It is important to do this, because
Algol, PL/I and COBOL and every other language designed from scratch
by a committee has suffered greatly from not getting the politics right.
When there is a prior agreement that only minor changes from a previous
language are allowed, the politics has often worked better, but I think
a new Lisp should admit new major ideas, so we have a problem.

	The problem is to avoid creating a language with two many
features that is not conveniently implementable as a whole.  This can
arise, because many of any committee members will have ideas that they
want to see included in the language.  There is a tendency to
compromise, whereby I'll agree that your idea is good if you'll agree to
put in mine.  One way to handle this might be to appoint a semi-dictator
with a veto on features.  He couldn't put anything in, but he could
exclude anything unilaterally.  Preferably, the semi-dictator should be
someone who has a good ability to understand the proposals that are made
including their joint effect on implementation but doesn't have
proposals of his own.  As many of you will notice, I don't qualify on
either ground.

	1. The language should be suitable as a classroom language.

	2. It should be suitable for correctness proofs.

	3. It should be implementable.

LISP and Prolog

	It would be nice to have a language that merged the good features
of LISP and Prolog.  Unless some ideas with which I am unfamiliar arise,
this may not be feasible for a language to be specified in the near future.
Here's the problem.  It's not hard to combine the functional notation of
LISP with the predicate notation of Prolog so that the user can use features
of both notations to specify the result he wants computed.  Indeed this
has been done several times already.

However, it has not yet been possible to provide such a language with a
standard computational algorithm that leads to reasonably efficient
computation when the user specifies what he wants computed by writing
the combined program.  LISP has a standard way of computing, i.e. 
call-by-value functional recursion.  Call-by-name and call-by-need
also work reasonably well.  Prolog has a standard way of computing also.
It fails to work well more often than LISP's way of computing, not because
LISP's way is better but because of Prolog's lesser specificity, i.e.
the Prolog programmer leaves the interpreter more chances to make a
mistake.  The combininations of logic and functional programming that
have been developed so far have no reasonably efficient standard way
of computing the object specified by the program.

This might be ok if there were a standard way of annotating the program
so that the control could be specified apart from the logic.  However,
this problem hasn't been solved either.


Big Floats - A minor feature

	I would like LISP to have a reasonable way of computing with
floating point numbers of arbitrary precision.  This would nicely
complement LISP's ability to compute with integers of arbitrary size
and would make LISP better than any existing language for computations
that require it.  Number theory is the domain I have in mind.  I
proposed this in the Common Lisp discussions, but the proposal was
ignored.  I suppose people thought it fell into the class of innovations
that had to be excluded from a standardization effort, and letting it
into the discussion would let in too much else.  I don't know enough to
disagree, although I am disappointed.

	Big floats are a minor feature.  There will be many proposals
for minor features, and there needs to be a good way of handling them.
I suppose big floats are distinguishable from many other features in
that their implementation, while requiring work, shouldn't tend to
interfere with the implementability of other features.  Maybe big floats
should be a standardized optional feature.  An implementer doesn't
have to include it, but if he does, the notation is determined.  I agree
that some work has to go into determining the statements to be used
to dynamically modify the precision being used.